perm filename CONGRU.TEX[CLS,LSP] blob sn#847176 filedate 1987-10-14 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	\beginsubSection{Congruent Lambda-lists for All Methods of a Generic Function}
C00012 ENDMK
CāŠ—;
\beginsubSection{Congruent Lambda-lists for All Methods of a Generic Function}

These rules define the congruence of a set of lambda-lists, including the
lambda-list of each method for a given generic function and the
lambda-list specified with {\bf defgeneric}, if present.  For {\tt
(SETF~{\it generic})} methods, these rules apply to the effective
lambda-list produced by combining the two specified lambda-lists according
to the rules in section ``nnn.''

\beginlist

\item{1.} Each lambda-list must have the same number of required
parameters.

\item{2.} Each lambda-list must have the same number of optional
parameters.  Each method can supply a different default for an optional
parameter.

\item{3.} If any lambda-list mentions {\bf \&rest} or {\bf \&key}, each
lambda-list must mention one or both of these.

\item{4.} If the {\bf defgeneric} lambda-list mentions {\bf \&key}, each
method must accept all of the keyword names mentioned after {\bf \&key} in
{\bf defgeneric}, either by accepting them explicitly, by specifying {\bf
\&allow-other-keys}, or by specifying {\bf \&rest} but not {\bf \&key}.
Each method can accept additional keyword arguments of its own.  The
checking of the validity of keyword names is done in in the generic
function, not in each method.

\item{5.} The use of {\bf &\allow-other-keys} need not be consistent
across lambda-lists.  If {\bf \&allow-other-keys} is mentioned in any
lambda-list, then any keyword arguments may be mentioned in the call to the
generic function.

\item{6.} The use of {\bf \&aux} need not be consistent across methods.

\endlist

\endsubSection%{Congruent Lambda-lists for All Methods of a Generic Function}

\beginsubSection{Named Arguments in Generic Functions and Methods}

When a generic function or its methods mentions {\bf \&key} in a
lambda-list, the specific set of named arguments accepted by the generic
function varies depending on the applicable methods.  The named arguments
accepted by the generic function for a particular call are the union of
the named arguments accepted by any applicable method and the named
arguments mentioned after {\bf \&key} in the {\bf defgeneric} form, if
any.  There is no attempt to exclude methods that are applicable but are
not actually called.  Note that in standard method combination, all
applicable methods are potentially callable if {\bf call-next-method} is
used.  A method that has {\bf \&rest} but not {\bf \&key} does not affect
the set of acceptable named arguments.  If the lambda-list of any
applicable method or of the {\bf defgeneric} form contains {\bf
\&allow-other-keys}, all named arguments are accepted by the generic
function.

The lambda-list congruence rules require that each method accept all of
the named arguments mentioned after {\bf \&key} in the {\bf defgeneric}
form, by accepting them explicitly, by specifying {\bf
\&allow-other-keys}, or by specifying {\bf \&rest} but not {\bf \&key}.
Each method can accept additional named arguments of its own, in addition
to the named arguments mentioned by the {\bf defgeneric} form.

For example, suppose there are two methods defined for {\tt width}
as follows:

\screen!

(defmethod width ((c character) &key font) ...)

(defmethod width ((p picture) &key pixel-size) ...)

\endscreen!

\noindent Assume that there are no other methods and no {\bf defgeneric}
for {\tt width}. Then the evaluation of the following form is and error
unless {\tt x} is both a character and a picture---the acceptable
arguments are determined by the applicable methods, not by all methods.

\screen!

(width x :font 'foo :pixel-size 10)

\endscreen!

\endsubSection%{Named Arguments in Generic Functions and Methods}